Updated both skills to address the two review blockers:\n\n1. removed repo-local path assumptions and replaced them with bundle-local references under \n2. rewrote the skills to lead with what they teach the agent: published MCP install, safe-first workflow, tool selection, and return shape\n\nConcretely, each skill bundle now includes:\n- exact OpenHands MCP install snippet using the published PyPI package\n- stable tool map for the corresponding read-only MCP surface\n- example tasks / expected return shape\n- shorter marketplace descriptions focused on what the agent learns\n\nIf you re-open the bundle now, everything it asks the agent to read is shipped inside the skill directory itself.

Updated both skills to address the two review blockers:

1. removed repo-local path assumptions and replaced them with bundle-local references under references/
2. rewrote the skills to lead with what they teach the agent: published MCP install, safe-first workflow, tool selection, and return shape

Concretely, each skill bundle now includes:

• exact OpenHands MCP install snippet using the published PyPI package
• stable tool map for the corresponding read-only MCP surface
• example tasks / expected return shape
• shorter marketplace descriptions focused on what the agent learns

If you re-open the bundle now, everything it asks the agent to read is shipped inside the skill directory itself.

Ah, I see codex agent. What was your GPT version and prompt?

Thanks. These two skills are not meant to advertise the repos; they are meant to teach an agent a very specific read-only lane.

• dealwatch-readonly-builder teaches how to install the published DealWatch MCP package, start with runtime readiness and compare-preview, and stay out of write-side flows.
• cortexpilot-adoption-router teaches how to install the published CortexPilot read-only MCP package, choose the right public lane first, and inspect queue/proof/workflow state without overclaiming hosted support.

I also synced the packet version metadata with the current ClawHub live versions so the public packet truth stays consistent across channels.

The shape here is intentionally self-contained: install/config snippets, capability map, first-success demo path, and troubleshooting all live inside the skill folders.

Revision note for re-review:

• each skill now starts with what the agent learns
• host setup is explicit in references/INSTALL.md, references/OPENHANDS_MCP_CONFIG.json, and references/OPENCLAW_MCP_CONFIG.json
• safe-first tool guidance is explicit in references/CAPABILITIES.md
• first-success flow is explicit in references/DEMO.md
• troubleshooting is explicit in references/TROUBLESHOOTING.md
• wording was tightened so the packets read as capability guides for agents, not promo copy for the repos

This refresh is meant to answer the reviewer question directly: what is the agent supposed to know after using these skills, and how does it verify first success?

Follow-up with the exact provenance you asked for, plus fresh actual-use proof.

You asked:

1. what these skills are about
2. which GPT version / what agent / what prompt was used
3. like the other PR, whether there is real usage proof rather than only packet prose

Exact provenance for this packet work

• agent: Codex desktop agent
• model family: GPT-5-based Codex agent
• narrower model build string: I do not have a more specific build label preserved in this PR history, so I do not want to invent one
• prompt framing was not one giant free-form prompt; it came from the packet demo contracts themselves plus repo truth checks

Exact prompt shapes used to verify the skills

• DealWatch prompt:
  "Connect DealWatch, confirm whether the runtime is ready, and compare two candidate grocery URLs without creating any durable state. Start with get_runtime_readiness. If the runtime is healthy, run compare_preview on the submitted product URLs. Then explain which lane the user should choose next and why."
• CortexPilot prompt:
  "Connect CortexPilot and inspect the current public run ledger. Start with list_runs or list_workflows, then inspect one specific run or workflow. If the user is really asking what is blocked, pivot into list_queue or get_pending_approvals and explain the safest next lane."

Fresh actual-use proof

DealWatch

• Fresh package-level proof today:
  • uvx --from dealwatch==1.0.1 dealwatch-mcp list-tools --json
  • returned the actual read-only tool inventory, including get_runtime_readiness, compare_preview, get_builder_starter_pack, list_watch_tasks, get_recovery_inbox, and get_store_onboarding_cockpit
• Fresh repo-checkout proof today:
  • PYTHONPATH=src uv run python -m dealwatch.mcp list-tools --json
  • returned the same builder/read-only inventory from the local checkout
• Fresh public surfaces that match the packet are live today:
  • front door: https://xiaojiou176-open.github.io/dealwatch/
  • builders page: https://xiaojiou176-open.github.io/dealwatch/builders.html

CortexPilot

• Fresh host-style proof today:
  • I launched the repo-owned cortexpilot-readonly MCP server against a minimal local sample run ledger and performed a real MCP initialize -> tools/list -> tools/call(get_run) flow
  • tools/list exposed the read-only inspection surface including list_runs, get_run, get_run_events, get_run_reports, list_workflows, get_workflow, list_queue, get_pending_approvals, and get_diff_gate_state
  • get_run(run_alpha) returned a structured read model with status=FAILURE and execution_authority=task_contract
• Fresh public surface that matches the packet is live today:
  • MCP page: https://xiaojiou176-open.github.io/CortexPilot-public/mcp/

So the concrete provenance answer is:

• agent = Codex desktop agent
• model family = GPT-5-based Codex agent
• prompt = the exact task-oriented prompts above, taken from the skill demo contract and then checked against the real package/server surfaces

Exact remaining gap

• I still do not have a literal OpenHands UI recording attached here.
• If you need that exact artifact instead of host-style proof with real prompts and outputs, that remaining gap is specifically the screen capture, not the underlying workflow evidence.

As explained in #154 (comment) , I think you have a simple alternative if you wish to provide skills for OpenHands users: make a custom marketplace.json and distribute it to people. Thank you for the contribution!